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ABSTRACT 

We  present  a  new  protocol,  called  the  Delay /Re-Read  Protocol,  for  controlling  con- 
current access  to  a  database.  The  protocol  uses  a  combination  of  preventative  and 
corrective  measures  for  maintaining  consistency.  The  Delay  /Re-Read  Protocol  Is 
deadlock-free,  requires  no  backup  data,  and  does  not  abort  either  transactions  or  data- 
base writes. 


1.  INTRODUCTION 

The  problem  of  concurrency  in  databases  has  received  a  good  deal  of  attention  in 
recent  years.  Errors  resulting  from  unrestricted  concurrency  were  first  observed  by 
Eswaran  et.al.  (ESW|.  They  showed  that  unrestricted  concurrency  can  result  in  an 
inconsistent  database.  The  solution  proposed  was  that  each  transaction  lock  the  entity 
it  is  going  to  access.  Moreover,  such  a  locking  protocol  typically  adopts  so-called  "two 
phase  locking",  which  consists  of  a  "growing  phase",  and  a  "shrinking  phase".  In  the 
growing  phase  a  transaction  collects  the  locks  that  it  requires,  and  in  shrinking  phase  it 
releases  them.  A  transaction  cannot  request  any  further  locks  once  it  has  released  any 
lock.   A  disadvantage  of  two-phase  locking  is  that  it  is  not  deadlock- free. 

Since  then  many  variations  on  locking  have  been  proposed  [BAYb,  ELL],  and  it  has 
been  demonstrated  that  locking  achieves  somewhat  better  results  when  the  database  is 
structured  as  a  hierarchy  [KED,  SIL].  However,  the  use  of  locking  to  maintain  con- 
sistency is  an  entirely  preventive  measure  i.e.  it  tries  to  prevent  any  view  of  the  database 
from  becoming  inconsistent.  For  this  reason  locking  assumes  the  worst  case  and  is  often 
overly  restrictive.  In  an  effort  to  relieve  the  tight  restrictions  of  locking  protocols,  Kung 
[KUN]  proposed  a  corrective  measure  for  concurrency  control  in  which  a  transaction  is 
permitted  to  see  an  inconsistent  state,  but  its  view  will  be  later  'corrected'  and  made 
consistent. 

In  the  present  paper  we  present  a  new  protocol,  which  utilizes  both  preventative 
and  corrective  techniques.  The  protocol,  which  we  call  the  Delay/Re-Read  Protocol, 
acts,  on  the  one  hand,  in  a  corrective  fashion  by  sometimes  forcing  a  transaction  to  re- 
read some  data;  it  does  so  upon  recognizing  that  a  transaction  has  read  an  inconsistent 
set  of  data.  The  protocol  acts,  on  the  other  hand,  in  a  preventative  fashion  by  some- 
times imposing  a  delay  before  permitting  a  transaction  to  write  to  the  database^  it  does 
so  upon  recognizing  that  such  a  write  might,  at  the  present  time,  jeopardize  the 
integrity  of  the  database. 

This  paper  is  organized  as  follows.  In  Section  2  we  present  our  model  of  a  database 
system.  In  Section  3  we  define  our  notion  of  consistency  and  present  some  results  relat- 
ing consistency  to  the  ordering  of  basic  actions  of  transactions.  In  Section  4  we  present 
the  Delay /Re-Read  Protocol  and  prove  that  it  is  both  consistent  and  deadlock-free.  In 
Section  5  we  discuss  some  aspects  of  the  Delay /Re-Read  Protocol,  including  its  applica- 
tion to  distributed  databases. 


2.   SYSTEM  MODEL 

We  consider  the  database  to  be  a  collection  of  distinct  named  objects,  called  enti- 
ties, together  with  assertions  about  the  values  of  the  entities.  These  assertions,  called 
integrity  constraints  are  often  not  explicitly  states;  indeed,  the  space  required  for  full 
specification  of  all  integrity  constraints  might  exceed  that  required  for  the  database 
itself.  Nonetheless,  whether  explicitly  stated  or  not,  consistency  constraints  are  present 
and  they  govern  the  interactions  of  operations  upon  entities.  A  database  which  satisfies 
all  of  the  integrity  constraints  is  said  to  be  in  a  consistent  state. 

In  order  to  formalize  our  moded,  we  present  some  definitions. 

We  denote  the  set  of  entities  in  the  database  by  "E".  Such  an  entity  may  be  read 
or  written  indivisibty. 


Definition  2.1.  A  transaction  with  unique  transaction  number  k,  denoted  T  ,  is  a  set 
of  actions 

Tk={tft!u 

together  with  a  linear  ordering1  <rt,  on  Tk .  As  a  notational  convenience,  we  use  the 
subscripts  on  the  actions  to  reflect  this  linear  ordering,  viz.  i<j  implies  f*<ri£y.  For 
each  t€[l,p^],  tf  is  a  4-tuple 

tf=(k,a?,e?,UU 
where 

(1)  k  uniquely  identifies  the  transaction  to  which  <*  belongs 

(2)  a*€{R,  W},  called  the  operation,  denotes  either  Read  or  Write 

(3)  efeE  denotes  the  entity  upon  which  the  operation  a*  is  performed 

(4)  UtkC2E,  called  the  use  set 

P 

Clearly,  <  p  is  meant  to  reflect  the  temporal  ordering  of  the  individual  actions  of 
Tk .  The  use  set  Utk  of  tk=(k,ak,ek,U^  is  the  empty  set  if  a*=R;  consequently,  we 
may  often  omit  (/,-  when  writing  a  Read  transaction: 

ttk  =  (k,R,e?) 
In  case  a*=W,  then  £/*  denotes  the  subset  of  entities  which  are  used  to  compute  the 
new  value  of  c*;  consequently,  we  may  often  use  a  "function"  notation  when  writing  a 
Write  transaction: 


1  Recall:  a  partial  ordering  <ona  set  X  is  a  subset  <  C X  X  X  for  which  ( a ,  b  )e  <  and  ( 6 ,  a  )e  < 
implies  a  =  b ,  and  for  which  (fl,6)€<  and  (&,c)€<  implies  (fl,c)€<;  (fl,o)6<  is  usually  written 
a  <  6 ;  if  a  fC  6  and  a^b  then  we  write  ff  <C6;  ^  is  said  to  be  a  linear  ordering  on  X  if  for  every 
a  ^StX,  either  a  <  b  or  b  <  a . 


Our  model  imposes  some  additional  restrictions  upon  a  transaction,  viz. 

(1)  all  Reads  must  precede  all  Writes; 

(2)  the  use  set  for  a  Write  transaction  must  include  the  entity  being  written,  i.e.  the 
new  value  of  an  entity  is  a  function  of  its  old  value  (among  other  things),  and; 

(3)  an  entity  must  be  read  before  it  can  appear  in  the  use  set  of  any  Write. 
Formally,  we  have  the  following. 

Definition  2.2.   A  transaction  Tk  =  {J*},-^  is  said  to  be  well-formed  if  and  only  if  the 
following  conditions  hold: 

(1)  for  each  pair  of  actions  tfttj£T*t  a*=R  implies  either  i<j  or  ay=R 

(2)  if  tf  =  (*,  W,e}(  Uf) )  then  ef  is  in  Uf 

(3)  if  tf={k,Wtef{U!))  then  for  every  yet/*  there  exists  tf  (j<i)  for  which  f/=(k,  R, 

y). 

P 

Our  model  is  thus  a  generalization  of  Papadimitriou's  "two-step  restricted"  model 
[PAPb],  in  which  our  restrictions  (2)  and  (3)  with  J7*={c*}  reduce  to  the  simpler  res- 
triction that  an  entity  must  be  read  before  it  can  be  written. 

3.   CONSISTENCY 

We  assume  that  a  given  transaction,  T  ,  transforms  the  database  from  one  con- 
sistent state  to  another  consistent  state  (although  the  database  may  temporarily  be  in 
an  inconsistent  state  while  T  is  ongoing).  Our  goal  is  to  allow  multiple  transactions  to 
be  active  concurrently,  and  yet  to  ensure  that  the  database  will  finally  end  up  in  a  con- 
sistent state. 

The  notion  of  concurrent  execution  of  multiple  transactions  is  captured  in  the  fol- 
lowing. 


Definition  3.1.    Let  T1,  .  .  .  ,  Tn  be  transactions.    A  schedule,  S,  for  Tl,  .  .  .  ,  Tn  is 

the  set  of  actions 


S=  U  T 

n 

together  with  a  linear  ordering,  <s,  on  S,  for  which  U  fs5r»C<$. 

•=i 

p 


As  before,  the  relation  <5  is  meant  to  reflect  temporal  ordering  (with  truly  simul- 
taneous actions  having  an  "effective"  temporal  ordering  imposed  by  <s)-  Since  we  are 
interested  in  only  those  schedules  which  correspond  to  the  (possibly  concurrent)  execu- 
tion of  the  individual  transactions  Tk ,  it  follows  that  if  f*<ri  tl-  then  we  must  have 

n 

f*<5  tj]  hence  the  requirement  that  U  <j'C<5- 

The  aim  of  any  concurrency  control  method  is  to  allow  only  those  schedules  which 
transform  the  database  from  one  consistent  state  to  another.  Serializ ability  [ESW, 
PAPa]  has  been  generally  accepted  as  the  consistency  criteria  for  schedules.  Informally, 
serializability  holds  that  a  schedule  for  transactions  Tl,  .  .  .  ,  Tn  is  consistent  if  the 
state  of  the  database  after  executing  the  schedule  is  the  same  as  it  would  have  been  had 
the  transactions  been  executed  one  after  another  in  some  order.  Note  that  the  order 
(corresponding  to  some  permutation  {n-,}  "=1  of  [l,n])  is  not  specified. 

Given  a  schedule,  S,  which  satisfies  this  notion  of  consistency,  we  refer  to  the  per- 
muted serial  execution  Tn\  .  .  .  ,  T*"  as  an  Equivalent  Serial  Schedule  (ESS).  Such  an 
ESS  is  not  necessarily  unique. 

Since  our  model  requires  that  each  entity  be  read  before  it  can  be  written,  a 
schedule  S  can  be  checked  for  serializability  using  its  corresponding  precedence  graph, 
Gs  [ULL].  We  construct  the  graph  as  follows.  The  nodes  correspond  to  the  transac- 
tions.  The  arcs  are  determined  by  the  following  rule: 

If  {i,R,x)<s{j,W,x)  or  {i,W,x)<s{j,W,x)  or  (i,W,x)<s(j ,R,z)  for  any  x, 
then  draw  an  arc  from  T*  to  T3 . 

A  schedule  S  is  serializable  if  its  precedence  graph  is  acyclic.  It  follows  that  we  can 
find  ESS(s)  for  S  by  topological  sorting. 

We  call  the  first  write  by  a  transaction  T,  the  critical  write  (denoted  Wc)  of  T. 
Note  that  {i,R  ,a)<s{i,Wc,b)  for  any  V. 


Lemma  3.1.  Let  Tl,  .  .  .  ,  Tn  be  well-formed  transactions  and  S  a  schedule  for  which 
l<i<y<n  implies  (i,  We,a)<s{j,  Wc,b).  The  precedence  graph  Gt  has  no  arc  from 
T3  to  Tx  (i<j)  if  for  every  (i,  W,  x)  in  S,  (j,  R,  z)  e  S  implies  either  z^x  or 
(i,W,x)<s(j,R,z). 

Proof.   There  are  only  3  possible  ways  that  Gs  can  have  an  arc  from  T3  to  Tx : 

(1)  {j,R,x)<s{i,W,x).   By  hypothesis,  (j,R,x)t  T3  and  j>i  implies  (t,  Vr,z)<5(.;*,i?,ar) 
which,  by  anti-symmetry  of  <5,  disallows  this  case. 

(2)  (j,  W1x)<s(i,  W,x).  Since  T3  is  well-formed,  we  have 

(;,/?,x)<5(;,^,x) 
whence  as  in  case  1 

(i,W7x)<s(j,R,x) 
and 

(i,W,x)<s(j,W,x) 


which,  by  anti-symmetry  of  <s,  disallows  this  case. 

(3)    (j,W,x)<s{i,R,x).   Since  T*  is  well- formed, 

(i,R,x)<s(i,Wefa) 
By  definition  of  critical  read, 

U,We,b)<s(j,W,x) 
whence 

U,W„*)<8(iW,*) 

However,  by  hypothesis  (since  i<j) 

(i,We,a)<s(j,We,b) 
so  this,  the  final  case,  is  also  disallowed  by  anti-symmetry  of  <5. 

Therefore  there  can  be  no  arc  in  Gs  from  T1  to  T* . 

p 


Theorem  3.2.  Let  Tl,  .  .  .  ,  Tn  be  well-formed  transactions  and  S  a  schedule  for 
which  l<»<y<«  implies  {i,We,a)<s(j,We,b).  The  precedence  graph  Gs  is  acyclic  if 
for  every  (i,W,x)  in  S  and  for  every  j>i,  (j,R,z)€S  implies  either  z^x  or 
(i,W,x)<s(j,R,z). 

Proof.  The  proof  is  by  contradiction.  Suppose  that  Gs  has  a  cycle  involving  nodes 
r",  .  .  .  ,  Tik  (k>l).  Let  i=min{ilt  .  .  .  ,ik).  Now,  for  every  je{ih  .  .  .  ,ik)  {j^i) 
we  have  j>i,  so  Lemma  3.1  applies,  and  there  can  be  no  arc  in  Gs  from  T}  to  Tx . 
Therefore,  the  presumed  cycle  involving  T*  is  contradicted. 

p 


Corollary  3.3.   Let  Tl,  .  .  .  ,  Tn  and  S  be  as  in  Theorem  3.2.   Then  S  is  consistent. 
Proof.   The  proof  is  immediate  since  Gs  is  acyclic. 

p 

Informally,  the  theorem  lays  down  the  condition  to  be  satisfied  by  the  schedule 
such  that  every  transaction  sees  a  consistent  state,  i.e.  the  set  of  values  returned  by  the 
Reads  of  the  transaction  is  such  that  it  is  the  same  as  the  set  of  values  of  these  entities 
in  some  consistent  database  state.  This  does  not  imply  that  all  the  Reads  must  be  per- 
formed on  the  same  consistent  state.  A  Read  can  be  performed  on  any  database  state, 
possibly  transitory  and  inconsistent,  but  the  set  of  values  read  by  all  Reads  must  be 
such  that  all  the  values  can  co-exist  in  some  consistent  database  state.  Theorem  3.2 
specifies  the  condition  when  this  is  satisfied.  This  theorem  is  the  basis  of  Delay /Re- 
Read  Protocol. 

In  the  following  sections  W,(z)  and  R{{x)  mean  same  as  (i,W,x)  and  (i,R,x)  respec- 
tively. 


4.  DELAY/RE-READ  PROTOCOL 

Not  all  schedules  satisfy  the  condition  of  Theorem  3.2.  The  purpose  of  the 
Delay /Re-Read  Protocol  is  to  take  any  schedule  and  "correct"  it  such  that  the  schedule 
satisfies  the  condition  of  the  theorem.  Each  transaction  is  submitted  to  a  Transaction 
Manager  which  assigns  a  Transaction  Process  (TP)  to  each  transaction.  Each  TP  sub- 
mits its  Read  and  Write  requests  to  a  process  called  the  Concurrency  Control  Process 
(CCP);  the  TP  awaits  permission  from  the  CCP  to  proceed  with  the  requested  Read  or 
Write.  There  is  also  a  History  File  which  only  the  CCP  reads  or  writes.  This  is 
different  from  a  "log  file"  which  might  record  all  activity  as  well  as  "backup"  data.  The 
History  File  records  only  a  finite  window  of  activity.  The  CCP,  on  receiving  a  Read 
request,  merely  records  it  in  the  History  File  (since  we  exert  no  control  over  the  Reads). 
However,  a  Write  can  be  delayed  by  the  CCP  according  to  the  following  scheme. 

The  Delay  /Re-Read  Protocol  is  used  by  the  CCP  to  ensure  that  any  schedule 
remains  consistent.  This  is  accomplished  by  a  combination  of  preventative  and  correc- 
tive measures.  On  one  hand,  the  Delay /Re-Read  Protocol  sometimes  causes  the  CCP  to 
delay  the  Critical  Write  of  a  TP,  thereby  delaying  all  of  the  Writes  of  the  associated 
transaction  (a  preventative  action);  on  the  other  hand,  the  Delay  /Re-Read  Protocol 
sometimes  causes  the  CCP  to  instruct  a  TP  to  re-read  some  entities  prior  to  proceeding 
with  a  Write,  thereby  assuring  that  the  Use  Set  for  the  Write  is  consistent  (a  corrective 
action). 

Since  we  do  not  allow  any  transactions  to  be  "backed  up,"  the  Delay /Re-Read  Pro- 
tocol must  ensure  that  whenever  any  transaction  performs  a  Write,  that  the  transaction 
will  be  able  to  complete.   For  this  reason,  the  initial  Write  of  any  transaction  is  critical. 

We  assume  that  when  the  transaction  is  submitted,  its  Read  and  Write  set  are 
known  (actually  the  read  set  can  be  computed  while  processing  the  transactions,  because 
the  method  does  not  use  this  information  until  all  the  Reads  are  done,  but  we  need  to 
know  the  Write  set).  This  assumption  has  been  made  in  SDDl  [BER],  and  is  implicit  in 
many  locking  protocols  in  order  to  determine  whether  to  request  a  shared  or  exclusive 
lock.  This  does  not  place  any  restrictions  on  what  transactions  can  read  or  write,  but 
when  the  transactions  is  submitted,  its  read  and  write  sets  should  be  known,  maybe  by 
doing  a  prepass  over  the  transaction  before  starting  to  process  it.  At  the  initial  Write, 
the  write  set  of  the  transaction  is  also  recorded  in  the  History  File.  If  the  write  set  of 
Tl  is  {x,y,z}  and  the  first  write  by  Tx  is  on  x,  then  it  will  be  recorded  in  History  File  as 
wi(x)wi(y)wi(z)Wi(x).  All  other  Reads  or  Writes  are  simply  recorded  as 
R {(entity -name)  or  W^entity-name). 

A  transaction  which  has  performed  at  least  one  Write  but  has  not  yet  terminated 
will  be  called  Active  and  Writing  (AW),  and  the  set  of  all  active  and  writing  transac- 
tions will  be  referred  to  as   the  Active  and  Writing  set  (AWS). 

Let  us  now  present  the  Delay /Re-Read  Protocol  formally. 

Let  x,y,zeE 

The  History  File,  H  is  maintained  as  a  string  over  the  alphabet2 


Actually,  the  "transaction  number"  f  c[l,n]  is  not  assigned  by  the  CCP  until  the  transaction's  crit- 


Let  an  ellipses  (...)  denote  an  arbitrary  string  over  J]  (possibly  of  length  zero). 

Let  AWS(j)  be  the  AWS  just  before  T3  performs  its  critical  write,  TP(j)  the  tran- 
saction process  of  T1 .   The  Delay  /Re-Read  Protocol  is  as  follows: 
Given  a  request  for  Wj(x{U)), 

1.  for  every  i£AWS(j)  do 

2.  {  for  every  yeU  do 

3.  {iftf=     •  •  w{{y)  •  •• 

4.  then  {  if  H^  •  •  •  W{{y)  ■  ■  • 

5.  then  await  H,(y) 

6.  if//^--  Wi(y)  •••  Hy(f)  •■  • 

7.  then  {  instruct  TP(j)  to: 

a)  re-read  y 

b)  re-compute  x(U) 

c)  re- request  Wy(a:((/)) 
halt 

} 
} 

} 

} 
9.  authorize  Wj{x(U)) 

Informally,  the  Delay /Re-Read  Protocol  ensures  that  there  is  no  arc  in  Gs  from  T1 
to  Tx  (where  {i ,We ,a)< s(j ,We ,b)).   This  is  done  by  noticing  the  situation  that 

a)  TJ  tries  to  use  some  ycE  which 

b)  T*  expects  to  have  written, 
and  by  ensuring  that 

c)  T%  has  indeed  performed  that  Write,  and  that 

d)  TJ,s  Read  (or  Re-Read)  of  y  occurs  after  P's  Write. 

Condition  b)  is  detected  in  line  3  of  the  Delay /Re-Read  Protocol;  the  need  for  the 
preventative  delay  of  step  c)  is  detected  in  line  4  of  the  Delay  /Re-Read  Protocol,  and; 
condition  d)  is  either  verified  in  line  6  of  the  Delay /Re-Read  Protocol  or  is  ensured  via  a 
corrective  re-read  by  line  8  of  the  Delay  /Re-Read  Protocol. 


Claim  5.1.   The  Delay /Re-Read  Protocol  is  consistent. 

Sketch  of  Proof.  The  above  discussion  illustrates  that  any  RAy)  occurs  after  all 
Wj(y)  that  may  occur  (for  i<j).  Thus,  the  hypotheses  of  Claim  3.3  are  satisfied,  and 
the  resulting  schedule  is  consistent. 


ical  write  is  authorized  (so  that  i<j  indeed  implies  (l,  W^,fl)<5(/,  We,6)).  Consequently,  the  Reads 
must  be  initially  recorded  with  some  other  transaction  identification.  Rather  than  exhibit  this  second 
identification  and  the  obvious  isomorphic  mapping  to  the  desired  transaction  numbers,  we  simply  exhibit 
the  transaction  numbers  throughout. 


p 


Claim  5.2.   The  Delay/Re-Read  Protocol  is  deadlock-free. 

Sketch  of  Proof.    Tj  is  made  to  wait  for  V  only  if  (i,  We1a)<s{j,  We,b).   Since  <5 
is  a  linear  ordering,  it  follows  that  no  deadlock  can  occur. 

P 


5.  DISCUSSION 

It  may  appear  that  the  history  string,  H,  grows  without  bound.  However,  there  is  a 
simple  method  by  which  we  can  prune  H.  We  observe  that  once  a  transaction  Tx  has 
"terminated"  (by  having  had  its  final  Write  authorized),  then  any  prefix  of  H  which 
involves  only  /?,-,  «;,-,  and  Wi}  may  be  discarded.  We  further  observe  that  the  perfor- 
mance of  a  Re-Read,  Rj{x),  obviates  the  need  for  any  previous  record  of  Rj{x);  thus  H 
can  be  further  pruned  of  such  i?y(z)'s. 

We  may  make  a  few  observations  concerning  the  "overhead"  of  the  Delay  /Re-Read 
Protocol.  Overhead  in  the  Delay /Re-Read  Protocol  is  of  two  forms:  "delay  overhead" 
corresponding  to  the  delay  of  a  Write  in  step  5,  and  "re- read  overhead"  from  step  7, 
which  includes  the  re-computation  of  x(U). 

It  is  apparent  that  if  H  is  pruned,  as  indicated  above,  then  there  is  no  overhead 
when  there  is  only  one  active  transaction.  Moreover,  there  remains  no  overhead,  even 
with  multiple  concurrent  transactions,  so  long  as  they  operate  on  disjoint  sets  of  enti- 
ties. Overhead  increases  only  as  the  interaction  among  transactions  increases,  vis-a-vis 
increasingly  overlapping  Use  Sets. 

Some  comparisons  are  possible  between  the  Delay /Re-Read  Protocol  and  Two- 
Phase  Locking  (although  we  make  no  attempt  here  at  a  full  comparison).  Delay  /Re- 
Read  Protocol  often  results  in  a  greater  degree  of  concurrency;  consider  the  following 
example  (where  left- to-right  vertical  alignment  indicates  temporal  ordering): 

T^RM  J?,(y)  Wi(x(x,y)) 

T2=       R2(x)R2(z)         W2(z(x,z)) 

Two-Phase  Locking  would  force  R2{x)  to  wait  until  after  Wi(x(x,y))}  effectively  forcing 
serial  execution,  while  the  Delay /Re-Read  Protocol  permits  full  concurrency,  as  shown. 

We  have  not  yet  indicated  how  the  Delay /Re-Read  Protocol  may  be  applied  in  a 
distributed  setting.  In  the  simplest  case,  we  envision  that  a  W^(a?)  should  make  a  local 
copy  of  the  new  value  of  x;  any  subsequent  RAx)f  including  Re-Reads  of  x,  which  are 
ordered  by  the  CCP,  will  be  made  to  read  the  recently-written  T,-site  value  of  x.  Thus, 
we  have  a  database  which  distributes  itself  adaptively,  according  to  the  most  recent 
Write. 

This  scheme  also  provides  a  solution  to  a  practical  implementation  problem.  Sup- 
pose   Tx    attempts    JVj-(x(£/))  where  the  computation  of  x(U)  is  expensive.     It  may 


happen  that  T*  is  forced  to  Re-Read  various  elements  of  U  and,  at  each  Re-Read,  also 
re-compute  x(U).  In  the  distributed  model  outlined  above,  T*  might  view  Wi(x(U))  as 
merely  a  request  to  write,  without  first  performing  the  expensive  computation.  Only 
once  the  Write  has  been  authorized  by  the  CCP,  does  T*  proceed  with  the  computation 
of  x(U),  finally  performing  the  Write  locally.  Meanwhile,  all  R.{x),  which  are  directed 
by  the  CCP  to  Read  the  7^ -site  value  of  x,  are  simply  delayed  by  TP(i)  until  T%  finally 
performs  the  Write  of  x. 

0.   CONCLUSION. 

We  have  presented  a  new  protocol  for  controlling  concurrent  access  to  a  database 
which  uses  both  preventative  and  corrective  measures  for  maintaining  consistency,  and 
in  so  doing,  permits  a  high  degree  of  concurrency.  The  protocol  is  deadlock-free  and 
accomplishes  its  "forward  recovery"  without  the  need  for  backup  data,  without  the  need 
for  reversing  the  effects  of  any  Writes,  and  without  aborting  transactions. 

The  present  version  of  the  Delay /Re-Read  Protocol  ensures  consistency  vis-a-vis 
serialization.  We  are  working  toward  variations  on  the  Delay  /Re-Read  Protocol  which 
ensure  even  stronger  forms  of  consistency. 
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